Fix bug in -z handling of trailing NUL in input

The obvious way to fix this would be to adapt lines to split on null.

However, it's actually nontrivial to rewrite lines. In particular it has a
weird implementation to avoid a space leak. See:
https://gitlab.haskell.org/ghc/ghc/-/issues/4334

Also, while that is a small amount of code, it's covered by a rather
complex copyright and I'd have to include that copyright in git-annex.

So, I opted to filter out the trailing empty string instead.

Sponsored-by: Dartmouth College's Datalad project

diff --git a/CHANGELOG b/CHANGELOG
index 2457dc0c364729fb190ff7809bb0e5f9a2ee301b..21b6fb0acba084a507dba9cd22d9d6157ea631df 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -65,6 +65,7 @@ git-annex (10.20230408) UNRELEASED; urgency=medium
     transition, and suggest using one of the options, or setting
     annex.synccontent.
   * sync: Added -g as a short option for --no-content.
+  * Fix bug in -z handling of trailing NUL in input.
 
  -- Joey Hess <id@joeyh.name>  Sat, 08 Apr 2023 13:57:18 -0400
 

diff --git a/CmdLine/Batch.hs b/CmdLine/Batch.hs
index 3439b3d580dd34bea6f1f99a2a1de9db9818ff7f..323f1d9f6e957b334c3b65bffc94fb16dd5fc823 100644 (file)
--- a/CmdLine/Batch.hs
+++ b/CmdLine/Batch.hs
@@ -115,7 +115,17 @@ batchLines (BatchFormat sep _) = do
   where
        splitter = case sep of
                BatchLine -> lines
-               BatchNull -> splitc '\0'
+               BatchNull -> elimemptyend . splitc '\0'
+
+       -- When there is a trailing null on the input, eliminate the empty
+       -- string that splitc generates. Other empty strings elsewhere in
+       -- the list are preserved. This is the same effect as how `lines`
+       -- handles a trailing newline.
+       elimemptyend [] = []
+       elimemptyend (x:[])
+               | null x = []
+               | otherwise = [x]
+       elimemptyend (x:rest) = x : elimemptyend rest
 
 -- When concurrency is enabled at the command line, it is used in batch
 -- mode. But, if it's only set in git config, don't use it, because the

diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn b/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
index 24d6ede1e5323782285ae7eedce7078c81dd3a10..f026cf338009419d63a15cd04ec9e837f9c3dbd7 100644 (file)
--- a/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
@@ -42,3 +42,4 @@ and also was reported on 10.20230407 to not return anything causing us to stall:
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 
+> [[closing|done]] per my comments --[[Joey]]

diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment
new file mode 100644 (file)
index 0000000..78e2929
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-19T17:53:51Z"
+ content="""
+However, after successfully dropping all the keys with `--print0`, there
+is then this oddity:
+
+       git-annex: Batch input parse failure: bad key
+
+That's a bug in nul splitting when there's a trailing nul. Oops. I've
+fixed that.
+
+Also while I reproduced the rest of the behavior, I didn't see this part:
+
+       commitBuffer: resource vanished 
+
+I'm not sure which command that comes from. Probably I think the findkeys,
+if its entire output was not consumed for some reason.
+"""]]